home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
kermit.columbia.edu
/
kermit.columbia.edu.tar
/
kermit.columbia.edu
/
newsgroups
/
misc.19970626-19970929
/
000173_news@newsmaster….columbia.edu _Fri Aug 15 18:28:43 1997.msg
< prev
next >
Wrap
Internet Message Format
|
1997-09-28
|
4KB
Return-Path: <news@newsmaster.cc.columbia.edu>
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id SAA27900
for <kermit.misc@watsun.cc.columbia.edu>; Fri, 15 Aug 1997 18:28:43 -0400 (EDT)
Received: (from news@localhost)
by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id SAA25441
for kermit.misc@watsun; Fri, 15 Aug 1997 18:28:42 -0400 (EDT)
Path: news.columbia.edu!watsun.cc.columbia.edu!fdc
From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: Turn off error detection?
Date: 15 Aug 1997 22:28:35 GMT
Organization: Columbia University
Lines: 67
Message-ID: <5t2l6j$5vi$1@apakabar.cc.columbia.edu>
References: <1997Aug15.161848.25354@hrbicf>
NNTP-Posting-Host: watsun.cc.columbia.edu
Xref: news.columbia.edu comp.protocols.kermit.misc:7478
In article <1997Aug15.161848.25354@hrbicf>,
Mark T. Shirey <mts@icf.hrb.com> wrote:
: We want to send a 10KByte JPEG image file over a 2400 baud half-duplex
: satellite channel with a high bit error rate (1-in-1000).
:
: We want speed and will sacrifice image quality.
:
: Is there a graphics file format (that xv or ImageMagick can handle)
: that can suffer missing or corrupted bytes and still be a viewable image?
: (I'll also ask this question in a more appropriate venue if I can find one.)
:
: Can C-Kermit be told to turn off all error checking?
:
No.
: Or is BLOCK-CHECK 1 sufficiently lenient on, say, 8K packets
: to have very few retries even in a noisy environment?
:
Not really. But I don't think that's what matters.
What you really want to do is achieve streaming and minimize retransmissions.
To minimize retransmissions, pick a small packet length, thus reducing the
chance that any particular packet will be corrupted and, if it is, the amount
of time needed to retransmit.
At the same time, you want to minimize the turnaound delay between ACKs and
NAKs. Let's assume you are transferring from earth to earth through the
satellite. The satellite is what, 20,000 miles high? So a signal passes from
earth to the satellite in 0.1 second, and back to earth in another 0.1 second,
for a total of 0.2 seconds. A reply would take another 0.2 seconds.
The bit error rate is 1/1000, which translates to 1 byte out of 100. So if
your packet length is 100 or greater, chances are that every single one will
be damaged. So try setting the Kermit packet length to half that, or 50.
Now set the window size to (say) 30. So a windowful of packets will carry
about 1500 bytes of data, and this will take 1500 / 240 = 6.25 seconds from
end to end. So the first data packet arrives 50 / 240 + 0.2 = 0.4 seconds
after it was sent, and the reply comes back about 0.2 seconds later, so even
when a retransmission is requested, there is very little chance the window
will fill up, and thus the sender should be able send continuously.
BUT with a packet length of 50, probably half the packets will need to be
retransmitted, and then half the retransmitted ones will need to be
retransmitted again, and so on. So maybe a shorter packet would give better
results. I'll leave it to you to do the math and/or experimentation. The
tradeoffs are:
. The shorter the packet, the greater the ratio of protocol overhead to
actual data.
. The longer the packet, the greater the chance it will be damaged and
the more time it will take to retransmit.
So it's like a linear programming problem with a little Monte Carlo thrown in.
Some choice of packet length will maximize the troughput for this particular
connection (with its speed, delay, and noise characteristics).
By the way, C-Kermit 6.0.192 tries its best to handle this sort of situation
automatically, by dynamically adjusting the packet length to achieve the
best throughput for the connection. It would be intersesting to turn it loose
on this one!
Finally, note that if your image data contains lots of repeated bytes (bytes,
not bits), Kermit might compress it enough to make a surprising difference.
- Frank